昨天提到，當 Codex 開始自己工作後，我開始在意的，不再只是 Prompt。
而是三件事：
但這三個問題，不是我一開始就想出來的。
比較接近真實情況的是：
專案先出問題，規則才慢慢長出來。
今天不談理論。
先來看我目前使用 Codex 的四種開發場景。
有些是公開專案，有些不適合公開全部原始碼，但我會盡量保留足以理解問題與工程判斷的 Evidence。
我目前主要遇到的場景，大致可以分成四類：
Web / API 系統
├─ Scope Drift
Cloudflare Workers / D1 / Production Data
├─ Authority / Production Risk
Android / Windows Toolchain
├─ Environment Drift
Shared Agent Skills / Cross-Repo Governance
└─ Governance Drift
表面上看起來，它們都只是「寫程式」。
但真的讓 Codex 進去工作之後，問題完全不一樣。
第一類是最直覺的。
React 前端、API、資料讀取、權限、登入、管理介面。
這種專案最容易讓人產生一個錯覺：
反正 Codex 很會讀 Code，就叫它直接找問題、改完、測完。
一開始確實很好用。
例如我要新增一個欄位、調整一個畫面、補一個 API 行為，Codex 通常可以自己一路追：
UI
↓
API client
↓
Worker route
↓
domain logic
↓
database query
↓
tests
如果只是傳統 autocomplete，很難跨這麼多層。
但當 Agent 可以自己一路追到底之後，第一個問題也出現了。
原本只是：
幫我多顯示今天總共有幾個便當。
Agent 可能會開始發現：
這些想法可能都沒錯。
問題是：
這次任務根本沒有要求。
於是我第一次明確感受到：
Good idea ≠ Approved scope
這也是後來我開始加入：
這類規則的原因。
不是因為 Codex 不夠聰明。
剛好相反。
是因為它太容易看到更多可以做的事。
第二類場景，開始讓我真的緊張。
因為這裡已經不只是改 Code。
它會碰到：
而且同一個專案裡，可能同時存在：
local
POC
formal
legacy
remote-test
production
這時候，「改對程式」已經不等於「做對事情」。
更危險的是：
SQL 是對的，但跑在錯的 Database。
或：
Migration 本身沒問題，但套到了不該動的環境。
甚至：
Code 改得完全正確，但 Agent 誤判了這次是否允許 deploy。
後來我開始把環境與資料操作，當成一等公民。
例如在做 Remote D1 操作前，我越來越要求先確認：
這裡也開始出現一個很重要的概念：
Capability ≠ Authority
Codex 有能力執行：
wrangler d1 execute
wrangler deploy
不代表它每次都應該執行。
我後來開始把動作分級。
例如：
backend-only
bounded scope
tests pass
no migration
no remote data mutation
↓
可以繼續 deploy
但：
schema
migration
remote data mutation
auth semantics
production repair
↓
需要 Human Gate
到這一步，我才開始發現：
Agent 開發開始很像權限系統。
第三種場景，讓我看到的是另一種問題。
不是 Agent 亂改。
而是：
環境本身會騙人。
例如 Android 專案裡，明明你以為 Gradle、JDK、SDK 都已經設定好了，但實際上可能是：
JAVA_HOME 指向錯的位置PATH
這種問題很有趣。
因為 Agent 看到錯誤訊息後，很容易先懷疑 Code。
但 root cause 可能根本不是 Code。
而是：
Environment
這類專案讓我開始更重視：
Runtime identity
Toolchain identity
Execution environment
Agent 不只要知道「這個專案是什麼」，
還要知道「它現在到底在哪裡執行」。
這和 Web 專案很不一樣。
Web 專案最怕 scope drift。
Android / Windows 更常遇到的，是 execution drift。
這也是為什麼後來我的 Preflight 裡，慢慢不只檢查 Git。
也開始加入：
很多時候，這些檢查比重新讀十個 source file 更重要。
第四種場景，是最晚出現，但我覺得最有意思的。
一開始，每個 Repo 都有自己的規則。
例如：
這個 Repo 修改前要先做 preflight。
這個 Repo deploy 前要跑哪些測試。
這個 Repo 不可以碰 remote D1。
這個 Repo Windows 要有 fallback。
久了之後，我開始發現：
我是不是一直在複製同一套 Prompt？
於是一些流程開始被抽成 Skill。
例如：
最後甚至變成一個獨立的 shared governance repository。
這時候，問題又升級了。
原本只是：
某個 Repo 裡的一段 Prompt。
抽出去之後，就開始出現：
version
compatibility
rollout
consumer
breaking change
fallback
Agent Governance 自己也開始像軟體。
它需要：
這件事是我一開始完全沒想到的。
我原本只是想：
不要每次重複貼 Prompt。
結果最後長成：
Shared Agent Platform
↓
multiple repos
這也是我開始使用「Agent Engineering」這個詞，而不是只說 Prompt Engineering 的原因。
如果把今天這四種場景放在一起看：
| 場景 | 最常逼出的問題 |
|---|---|
| Web / API | Scope drift |
| Workers / D1 | Authority / Production risk |
| Android / Windows | Environment drift |
| Shared Skills | Governance drift |
一開始我以為只要 Prompt 寫得更完整就可以處理。
後來發現不是。
因為這四種問題，本質上都不是一句 Prompt 能永久解決的。
最早只有：
Prompt
↓
Implement
後來變成：
Prompt
↓
Plan
↓
Implement
↓
Test
再後來：
Intent
↓
Preflight
↓
Plan
↓
Plan Freeze
↓
Execute
↓
Verify
↓
Deploy Gate
↓
Evidence
↓
Handoff
而且每一層，幾乎都對應到某一次踩坑。
不是為了看起來專業。
是因為前一版不夠用了。
Agent 最難治理的地方，不是它不夠聰明。
而是：
它已經聰明到可以做太多事情。
當它只會補一行 Code 時，風險很有限。
當它可以：
需要設計的，就不再只是：
「我要怎麼讓它做得更好？」
而是：
「我要怎麼讓它知道，什麼時候不該做？」
這也是我後來開始把 Agent Workflow 拆成：
Context
Authority
Evidence
三個核心問題的原因。
這裡也先說明一件事。
這個系列裡，有些案例會來自公開 Repository。
有些則只會公開：
我不打算為了寫文章，把所有真實專案原始碼全部公開。
因為這系列想討論的不是：
「這個專案怎麼 clone？」
而是：
當 Coding Agent 開始參與真實工程，哪些判斷值得被留下來？
對我來說，足以重現決策的 Evidence，比公開全部 Code 更重要。
既然問題這麼多，最直覺的做法是：
把規則全部寫進 AGENTS.md 不就好了？
我一開始也差不多是這樣想。
結果後來發現：
AGENTS.md 寫太少會失控，寫太多一樣會失控。
甚至規則本身，還可能讓 Agent 變慢、重複探索、反覆執行同一套 ritual。
Day 3 會開始看：
AGENTS.md 到底應該放什麼？為什麼規則不是越多越安全？
iThome鐵人賽
看影片追技術